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Abstract — This paper describes an Earth Observation Sensor 
Web scenario based on the Open Geospatial Consortium’s Sensor 
Web Enablement and Web Services interoperability standards. 
The scenario demonstrates the application of standards in de- 
scribing, discovering, accessing and tasking satellites and ground- 
based sensor installations in a sequence of analysis activities that 
deliver information required by decision makers in response to 
national, regional or local emergencies. 

Index Terms — NASA, Geoscience, Sendees, Interoperability, 
Earth Science, Architecture, Sensor Web 

i. Overview 

NaSA has been experimenting with autonomous sensor 
webs to improve science return on its earth observing capabili- 
ties [1], Over the last five years, significant research has been 
performed in this area includes a wide range of scientific ap- 
plications and national priorities [2]. 

In support of the Open Geospatial Consortium’s (OGC) 
Web Services testbed Phase 4 (OWS-4), a team of researchers 
and technologists in the Earth observing field got together to 
apply the OGC services and sensor web standards in a scenario 
involving interoperable discovery, access and integration of 
geoscience data and sensor results. The goal was to showcase 
the applications of OGC standards within the Earth Observa- 
tion community and to demonstrate the value of interoperabil- 
ity in that environment [3], 

The team consisted of the NASA Goddard Space Flight 
Center (GSFC) Geoscience Interoperability Office (GIO) and 
the Real-time Software Branch, Washington University at St. 
Louis (WUSTL), Vightel Corporation, Noblis (formerly Mi- 
tretek), Innovative Solutions Inc., the Jet Propulsion Labora- 
tory (JPL), and George Mason University (GMU). 

The scenario aimed at providing Geographic Information 


System (GlS)-ready sensor and other infrastructure data to 
support a response to a simulated emergency. The particular 
subset of OWS-4 results accomplished by the Earth Observa- 
tion team used standard web services to task remote sensing 
satellites and to deliver hyperspectral data of the target area as 
user-customized classifier outputs. To find out more about the 
overall OWS-4 results, go to the 
http://www.opengeospatial.org website. 

The following suite of OGC standards were iiiiplemented 
by the various components of the scenario 
Sensor Observation Service (SOS) 

Sensor Planning Service (SPS) 

Sensor Alert Service (SAS) 

Web Processing Service (WPS) 

Catalog Service for the Web (CSW) 

Web Coverage Service (WCS) 

Web Feature Service (WFS) 

- Web Map Service (WMS) 

The scenario demonstrated the value of interoperability in 
Quickly discovering relevant and up-to-date assets, 
services and sensors 

Ordering real-time custom products with guaranteed 
delivery to any location in the world 
Subscribing to data/service/sensor feeds and getting 
real-time notifications when information is available 
Integrating needed data on the web for free (using a 
special click-through license for trusted identity pro- 
viders) 

II. USER/OPERATIONS CONCEPT 

The NASA-centric scenario linked the sensor services capa- 
bilities by tasking multiple satellites to image the target site 
based on a request from an emergency response analyst [4]. 
One of the satellites used in the scenario demonstration was 



NASA’s Earth Observing-1 (EO-1; http://eol.gsfc.nasa.gov) 
satellite which, due to having the nearest next in-view time for 
the target, resulted in being the satellite that was tasked. 

The scenario (Figure 1) began by allowing the user to iden- 
tify the target location on a web map client selecting the area 
of interest and then automatically using the latitude and longi- 
tude returned by the map to generate a tasking request for tire 
EO-1 satellite. The satellite images of the target were taken on 
the first available overflight opportunity as determined by the 
Sensor Planning Service for each of the satellites. Data proc- 
essing activities were then chained together as a sequence of 
processing steps into a workflow: that retrieved die Level 1G 
image data from the satellite Sensor Observation Service, sub- 
setted it, re-projected the subset into a different grid required 
by an algorithm, ran the algorithm against the data, and dis- 
played the output on a web map client. 

All data, services and analysis outputs used in the process 
were discovered by querying the NASA Earth Science Gate- 
way (ESG) [5], ESG facilitates discovery and access of 
NASA’s extensive Earth Science infonnation systems and re- 
search results. In doing so, ESG supports the science commu- 
nity and NASA’s partners. ESG and the other elements of the 


ESG in particular provides local and distributed search and 
harvest; visualization of remote data via Web services; pub- 
lishing of data and services, and user personalization. In order 
to function as a GEOSS interoperability platform, ESG is in- 
corporating standards-based technologies to support the ob- 
serving, processing, and dissemination methods provided by 
various parties while retaining their ownership and operational 
responsibilities for such purposes. 

III. SATELLITE TASKING AND MONITORING 

The EO-1 satellite tasking and data delivery part of the testbed 
was based on the OGC standard Geobliki data node providing 
tasking access and data delivery of EO-1 hyperspectral data to 
a sequence of processing nodes that run a flood classifier 
thumbnail generator. The Geobliki data node (developed by 
Vightel and Innovative Solutions) [7] contains a Sensor Ob- 
servation Service (SOS), a Sensor Processing Service (SPS), 
and a Sensor Alert Service (SAS). 

The Geobliki SPS allowed users to query the EO-1 orbital 
predictions to determine tasking opportunities for acquiring the 
target location on an upcoming orbit. The lat/lon values sup- 
plied by the map query to the EO-1 planning web site returned 
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Figure 1 OWS-4 Earth Observing Demo Scenario 


testbed implement consensus-based, publicly accessible stan- 
dards for maximum interoperability, and employ web services 
in support of Service Oriented Architectures. As such, they can 
contribute to larger System-of-Systems concepts such as the 
Global Earth Observing System of Systems (GEOSS) [6]. 


the next 5 in-views for the satellite. In addition, another satel- 
lite SPS provided by the SPOT mission participants 
(http://services.eoportal.org) in the OWS-4 testbed also re- 
turned tasking opportunities. The second SPS demonstrated 
the ability of discovering taskable assets across the earth ob- 
serving domain. In the OWS-4 demonstration, the next EO-1 






in-view happened sooner than that of the SPOT satellite for the 
target area, so as a result, a tasking request was generated and 
submitted to the EO-1 priority replacement web page. 

Geobliki monitored the EO-1 operations status web site to 
determine when the submittal changed from "pending" to "exe- 
cuted" and then submitted a request to the USGS data process- 
ing center to order the EO-1 Level 1G data product resulting 
from that acquisition. When the Level 1G product became 
available, an Email was sent to the Geobliki client. The Geob- 
liki retrieves the data product and supplies that data to the 
workflow engine to start the classifier run. 

IV. Workflow and web processing service 

The flood classifier algorithm was wrapped in a standard proc- 
essing service by the WUSTL developers providing standard 
OGC Web Processing Service (WPS) interfaces for GetCapa- 
biliti.es, DescribeProcess, and Execute 

(http://webapps.datafed.net). The WPS capabilities were 
documented in an XML formatted package that was published 
and harvested by sensor web registries (i.e., the ESG). Input 
sources for tire detection algorithm, were also identified in the 
WPS description so that users could search for the data nodes 
that supply that type of data and and in addition, could request 
additional runs on-demand. In addition, those capabilities 
could be imported and modified to create new outputs. In this 
workflow, the WPS is a binary grid processing service. The 
binary operator service combined two grids as inputs, per- 
formed a calculation on them, and generated an output grid. 

The Business Processing Execution Language (BPEL) was 
used as the workflow engine in the testbed, which required that 
interfaces to the processing service must use SOAP/WSDL 
protocols. As a result, the execution of the classifier algorithm 
processing service was conducted through SOAP/WSDL inter- 
faces rather than the OGC WPS Execute interface. 

The processing service chain was controlled by the GMU 
BPEL engine that retrieved 2 selected bands from the Level 
1G Hyperion data product provided by the Geobliki data node 
(http://geobrain.laits.gmu.edu). Those two single band 
GEOTIFF files were run through a Web Coordinate Transfor- 
mation Service (WCTS) to convert them from Universal 
Transverse Mercator (UTM) projection to WMS-84 projection 
needed by the algorithm, which then were fed into a flood de- 
tection algorithm processing service. This process resulted in 
a final output product which was cataloged. 

Figure 2 outlines the steps of the BPEL workflow execution, 
■ which were translated into a pseudo-code script that executed 
the desired workflow. In addition, a WPS capabilities docu- 
ment was cataloged and contained the location of the open 
source algorithm, the description of the output feature, and the 


description of the input sensors. 
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Figure 2 BPEL Workflow Diagram 
V. CONCLUSIONS 

Tire demonstration proved to be successful in showing how 
disparate systems and components can come together meaning- 
fully and on-demand in order to accomplish scenario objec- 
tives and to assist the decision makers in getting the data that 
they need rapidly. The demonstration success is attributed to 
the fact that each system/component participating in the sce- 
nario implemented consensus-based open standards and ser- 
vices. Interoperability and web services enabled the disparate 
systems/component to work together to exchange data and 
information. 

In terms of future work, the demonstration highlighted the 
need for the following: 

Geospatial Digital Management standards in the sen- 
sor tasking step in order to make sure that only au- 
thorized users are able to task and control the sensors 
Further decouple services in the BPEL engine in or- 
der to create a more flexible and extensible overall 
system 

- ' Efficient methods to task sensors in parallel to sup- 
port further international collaboration 
Better understanding of requirements for data access 
of “raw” and “processed” sensor data, including the 



relationship between OGC SOS, WCS and WPS 
specifications 

Continued work on standards-based web service ori- 
ented infrastructures to provide on-demand data to 
decision makers 

VI. FUTURE WORK 

During the Spring and -Summer of 2007, the sensor web test- 
bed will be expanded to link satellites, an unmanned aerial 
vehicle (UAV), and in-situ ground sensors in an ad hoc virtual 
observatory casting every node as a web sendee that complies 
with OGC standards. The next scenario is in support of wild- 
fire management. 

The scenario will start with a set of large wildfires of na- 
tional importance being selected for sensor web coverage in 
the Western United States. The selected fires will fall within 
an upcoming UAV flight path. Local weather data for the 
demo will be provided by Remote Access Weather Station 
(RAWS) sensors installed in field locations along the UAV 
flight line. The Terra satellite Moderate Resolution Imaging 
Spectroradiometer (MODIS) and Advanced Spacebome 
Thermal Emission and Reflection Radiometer (ASTER) in- 
struments direct readouts of hot pixels within the flight path 
near the selected wildfires will be used to identify the most 
recent fire locations. EO-1 and UAV data acquisitions of se- 
lected targets will be requested based on the most recent fire 
locations and data products will be automatically delivered 
according to user-customized subsetting and classification 
specifications. 

Wildfires will be selected from the National Interagency 
Fire Center (http://www.nifc.gov/) daily situation postings.' At 
this website, each fire is identified by fire name, origination 
point latitude/longitude, and reported start time. Tire originat- 
ing location for each of the fires will be retrieved by a web 
client. The originating fire locations within the UAV flight 
path Will serve as the starting point for construction of se- 
quences of activities that identify the most recent location of 
each wildfire and then blanket those locations with autono- 
mously triggered follow-up acquisitions by the higher resolu- 
tion assets. 

MODIS direct readout hot pixel detections will be provided 
by the direct readout antenna in Salt Lake City at the Forest 
Service Remote Sensing Applications Center (RSAC). 
ASTER classifier outputs will be available at the Jet Propul- 
sion Laboratory (JPL) ASTER website and will be used to 
provide thermal detection data of particular targets at 30 me- 
ters per pixel instead of 250 meters per pixel that is provided 
by MODIS. 

The calculated locations and pixel values from ASTER and 


MODIS will be collected by a web client based on a query for 
wildfires. The hot pixel data will be rendered as multi-colored 
JPG files and overlaid on a map. 

The recent fire locations will be fed into SPS's for EO-J and 
the UAV and the exact targeting opportunities will be calcu- 
lated based on the MODIS and ASTER detection results. 
Tasking requests will be constructed and submitted to the 
SOS's for EO-1 and the UAV to trigger the nearest available 
data collection opportunity of those targets based on the in- 
formation provided by the SPS. The tasking requests will con- 
tain the location and timing of the future targets of opportunity 
relative to the flight lines of each platform and in addition will 
contain requests to run on-board classifiers that will execute on 
EO-1 and the UAV immediately after the data collection has 
occurred. 

The EO-1 and UAV websites will be monitored until con- 
firmation that the image requests have been executed. Auto- 
mated retrieval of the thumbnails produced on-board EO-1 and 
the UAV will be performed by the client as soon as those prod- 
ucts are available on their respective data nodes. On-board 
classifier results will be retrieved by the client based on identi- 
fying that the target acquisition has been executed. If the on- 
board results indicate detection of a phenomena, an alert will 
be set autonomously by the EO-1 and UAV SOS’s. The on- 
board thermal thumbnail will be converted/rendered into a .jpg 
file with a legend by a web rendering service so the results can 
be displayed on a map by the client. 

Automated delivery of full Level 1R and Level 1G data 
products, high resolution browse imagery, and other detection 
classifier outputs from WPS/WCTS implementations on the 
ground will also be chained together in workflow sequences. 
Those results will be made available for retrieval or automati- 
cally delivered, depending on the size of the likely transfer 
(large files retrieved, small files delivered). 

The UAV is an Ikhana class (civilian version of the General 
Atomics Predator-B) that will fly out of Dryden with instru- 
ments from Ames Research Center (see 
http://suborbital.nasa.gov/platforms/aircraft/predator-b.htxnl 
for more information). 

EO-1 and UAV Level 1G data will be retrieved by a work- 
flow chain which will run web processing services and deliver 
classifier results consisting of entire images, not just the 
thumbnails for target area. 

The RAWS outputs from any installations near the fire are 
displayed on the web map client along with all the overlaid 
data products (on-board outputs, browse images, level 1 prod- 
ucts, classifier outputs, etc...) from EO-1 and the UAV. 
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EO-1 alerts will be used to trigger the UAV and UAV 
alerts will be used to trigger EO-1 acquisitions. This will be in 
addition to the use of MODIS and ASTER to trigger EO-1 and 
the UAV. All of this will occur in the same 20 hour block. 

Cloud cover predictions from the Draper Lab EPOS server 
will be used to distinguish between multiple potential fire tar- 
gets along the same flight line as part of a decision support tool 
used to create the automated workflow service chain. Other 
geoprocessing models will be added to provide a richer envi- 
ronment for triggering sensor web observation scenarios. 
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